home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Secrets 4 / Hacker's Secrets 4.iso / internet / ipng-ove.txt < prev    next >
Text File  |  1996-02-03  |  58KB  |  1,185 lines
  1. IP Next Generation Overview
  2.  
  3. May 14, 1995
  4.  
  5. Robert M. Hinden
  6.  
  7. ----------------------------------------------------------------------------
  8.  
  9. Abstract
  10.  
  11. This paper presents an overview of the Next Generation Internet Protocol
  12. (IPng). IPng was recommended by the IPng Area Directors of the Internet
  13. Engineering Task Force at the Toronto IETF meeting on July 25, 1994, and
  14. documented in RFC 1752, "The Recommendation for the IP Next Generation
  15. Protocol" [1]. The recommendation was approved by the Internet Engineering
  16. Steering Group on November 17, 1994 and made a Proposed Standard.
  17.  
  18. ----------------------------------------------------------------------------
  19.  
  20. Contents
  21.  
  22. 1 Introduction
  23.  
  24. 2.0 Key Issues
  25.  
  26. 3.0 History of the IPng Effort
  27.  
  28. 4.0 IPng Overview
  29.  
  30. 5.0 IPng Header Format
  31.  
  32. 6.0 IPng Extensions
  33.  
  34. 7.0 IPng Addressing
  35.  
  36. 8.0 IPng Routing
  37.  
  38. 9.0 IPng Quality-of-Service Capabilities
  39.  
  40. 10. IPng Security
  41.  
  42. 11. IPng Transition Mechanisms
  43.  
  44. 12. Why IPng?
  45.  
  46. 13. Where to Get Additional Information
  47.  
  48. References
  49.  
  50. Author Information
  51.  
  52. ----------------------------------------------------------------------------
  53.  
  54. 1. Introduction
  55.  
  56. This paper presents an overview of the Next Generation Internet Protocol
  57. (IPng). IPng was recommended by the IPng Area Directors of the Internet
  58. Engineering Task Force at the Toronto IETF meeting on July 25, 1994, and
  59. documented in RFC 1752, "The Recommendation for the IP Next Generation
  60. Protocol" [1]. The recommendation was approved by the Internet Engineering
  61. Steering Group on November 17, 1994 and made a Proposed Standard.
  62.  
  63. The formal name of this protocol is IPv6 (where the "6" refers to it being
  64. assigned version number 6). The current version of the Internet Protocol is
  65. version 4 (referred to as IPv4). This overview is intended to give the
  66. reader an overview of the IPng protocol. For more detailed information the
  67. reader should consult the documents listed in the reference section.
  68.  
  69. IPng is a new version of IP which is designed to be an evolutionary step
  70. from IPv4. It is a natural increment to IPv4. It can be installed as a
  71. normal software upgrade in internet devices and is interoperable with the
  72. current IPv4. Its deployment strategy was designed to not have any "flag"
  73. days. IPng is designed to run well on high performance networks (e.g., ATM)
  74. and at the same time is still efficient for low bandwidth networks (e.g.,
  75. wireless). In addition, it provides a platform for new internet
  76. functionality that will be required in the near future.
  77.  
  78. This paper describes the work of IETF IPng working group. Several
  79. individuals deserve specific recognition. These include Paul Francis, Bob
  80. Gilligan, Dave Crocker, Ran Atkinson, Jim Bound, Ross Callon, Bill Fink,
  81. Ramesh Govindan, Christian Huitema, Erik Nordmark, Tony Li, Dave Katz, Yakov
  82. Rekhter, Bill Simpson, and Sue Thompson.
  83.  
  84. 2.0 Key Issues
  85.  
  86. There are several key issues that should be considered when reviewing the
  87. design of the next generation internet protocol. Some are very
  88. straightforward. For example the new protocol must be able to support large
  89. global internetworks. Others are less obvious. There must be a clear way to
  90. transition the current large installed base of IPv4 systems. It doesn't
  91. matter how good a new protocol is if there isn't a practical way to
  92. transition the current operational systems running IPv4 to the new protocol.
  93.  
  94. 2.1 Growth
  95.  
  96. Growth is the basic issue which caused there to be a need for a next
  97. generation IP. If anything is to be learned from our experience with IPv4 it
  98. is that the addressing and routing must be capable of handling reasonable
  99. scenarios of future growth. It is important that we have an understanding of
  100. the past growth and where the future growth will come from.
  101.  
  102. Currently IPv4 serves what could be called the computer market. The computer
  103. market has been the driver of the growth of the Internet. It comprises the
  104. current Internet and countless other smaller internets which are not
  105. connected to the Internet. Its focus is to connect computers together in the
  106. large business, government, and university education markets. This market
  107. has been growing at an exponential rate. One measure of this is that the
  108. number of networks in current Internet (40,073 as of 10/4/94) is doubling
  109. approximately every 12 months. The computers which are used at the endpoints
  110. of internet communications range from PC's to Supercomputers. Most are
  111. attached to Local Area Networks (LANs) and the vast majority are not mobile.
  112.  
  113. The next phase of growth will probably not be driven by the computer market.
  114. While the computer market will continue to grow at significant rates due to
  115. expansion into other areas such as schools (elementary through high school)
  116. and small businesses, it is doubtful it will continue to grow at an
  117. exponential rate. What is likely to happen is that other kinds of markets
  118. will develop. These markets will fall into several areas. They all have the
  119. characteristic that they are extremely large. They also bring with them a
  120. new set of requirements which were not as evident in the early stages of
  121. IPv4 deployment. The new markets are also likely to happen in parallel with
  122. one another. It may turn out that we will look back on the last ten years of
  123. Internet growth as the time when the Internet was small and only doubling
  124. every year. The challenge for an IPng is to provide a solution which solves
  125. todays problems and is attractive in these emerging markets.
  126.  
  127. Nomadic personal computing devices seem certain to become ubiquitous as
  128. their prices drop and their capabilities increase. A key capability is that
  129. they will be networked. Unlike the majority of todays networked computers
  130. they will support a variety of types of network attachments. When
  131. disconnected they will use RF wireless networks, when used in networked
  132. facilities they will use infrared attachment, and when docked they will use
  133. physical wires. This makes them an ideal candidate for internetworking
  134. technology as they will need a common protocol which can work over a variety
  135. of physical networks. These types of devices will become consumer devices
  136. and will replace the current generation of cellular phones, pagers, and
  137. personal digital assistants. In addition to the obvious requirement of an
  138. internet protocol which can support large scale routing and addressing, they
  139. will require an internet protocol which imposes a low overhead and supports
  140. auto configuration and mobility as a basic element. The nature of nomadic
  141. computing requires an internet protocol to have built in authentication and
  142. confidentiality. It also goes without saying that these devices will need to
  143. communicate with the current generation of computers. The requirement for
  144. low overhead comes from the wireless media. Unlike LAN's which will be very
  145. high speed, the wireless media will be several orders of magnitude slower
  146. due to constraints on available frequencies, spectrum allocation, error
  147. rates, and power consumption.
  148.  
  149. Another market is networked entertainment. The first signs of this emerging
  150. market are the proposals being discussed for 500 channels of television,
  151. video on demand, etc. This is clearly a consumer market. The possibility is
  152. that every television set will become an Internet host. As the world of
  153. digital high definition television approaches, the differences between a
  154. computer and a television will diminish. As in the previous market, this
  155. market will require an Internet protocol which supports large scale routing
  156. and addressing, and auto configuration. This market also requires a protocol
  157. suite which imposes the minimum overhead to get the job done. Cost will be
  158. the major factor in the selection of an appropriate technology.
  159.  
  160. Another market which could use the next generation IP is device control.
  161. This consists of the control of everyday devices such as lighting equipment,
  162. heating and cooling equipment, motors, and other types of equipment which
  163. are currently controlled via analog switches and in aggregate consume
  164. considerable amounts of electrical power. The size of this market is
  165. enormous and requires solutions which are simple, robust, easy to use, and
  166. very low cost. The potential pay-back is that networked control of devices
  167. will result in cost savings which are extremely large.
  168.  
  169. The challenge the IETF faced in the selection of an IPng is to pick a
  170. protocol which meets today's requirements and also matches the requirements
  171. of these emerging markets. These markets will happen with or without an IETF
  172. IPng. If the IETF IPng is a good match for these new markets it is likely to
  173. be used. If not, these markets will develop something else. They will not
  174. wait for an IETF solution. If this should happen it is probable that because
  175. of the size and scale of the new markets the IETF protocol would be
  176. supplanted. If the IETF IPng is not appropriate for use in these markets, it
  177. is also probable that they will each develop their own protocols, perhaps
  178. proprietary. These new protocols would not interoperate with each other. The
  179. opportunity for the IETF is to select an IPng which has a reasonable chance
  180. to be used in these emerging markets. This would have the very desirable
  181. outcome of creating an immense, interoperable, world- wide information
  182. infrastructure created with open protocols. The alternative is a world of
  183. disjoint networks with protocols controlled by individual vendors.
  184.  
  185. 2.2 Transition
  186.  
  187. At some point in the next three to seven years the Internet will require a
  188. deployed new version of the Internet protocol. Two factors are driving this:
  189. routing and addressing. Global internet routing based on the on 32-bit
  190. addresses of IPv4 is becoming increasingly strained. IPv4 address do not
  191. provide enough flexibility to construct efficient hierarchies which can be
  192. aggregated. The deployment of Classless Inter- Domain Routing [2] is
  193. extending the life time of IPv4 routing by a number of years, the effort to
  194. manage the routing will continue to increase. Even if the IPv4 routing can
  195. be scaled to support a full IPv4 Internet, the Internet will eventually run
  196. out of network numbers. There is no question that an IPng is needed, but
  197. only a question of when.
  198.  
  199. The challenge for an IPng is for its transition to be complete before IPv4
  200. routing and addressing break. The transition will be much easier if IPv4
  201. address are still globally unique. The two transition requirements which are
  202. the most important are flexibility of deployment and the ability for IPv4
  203. hosts to communicate with IPng hosts. There will be IPng- only hosts, just
  204. as there will be IPv4-only hosts. The capability must exist for IPng-only
  205. hosts to communicate with IPv4-only hosts globally while IPv4 addresses are
  206. globally unique.
  207.  
  208. The deployment strategy for an IPng must be as flexible as possible. The
  209. Internet is too large for any kind of controlled roll out to be successful.
  210. The importance of flexibility in an IPng and the need for interoperability
  211. between IPv4 and IPng was well stated in a message to the sipp mailing list
  212. by Bill Fink, who is responsible for a portion of NASA's operational
  213. internet. In his message he said:
  214.  
  215.      "Being a network manager and thereby representing the interests of
  216.      a significant number of users, from my perspective it's safe to
  217.      say that the transition and interoperation aspects of any IPng is
  218.      *the* key first element, without which any other significant
  219.      advantages won't be able to be integrated into the user's network
  220.      environment. I also don't think it wise to think of the transition
  221.      as just a painful phase we'll have to endure en route to a pure
  222.      IPng environment, since the transition/coexistence period
  223.      undoubtedly will last at least a decade and may very well continue
  224.      for the entire lifetime of IPng, until it's replaced with IPngng
  225.      and a new transition. I might wish it was otherwise but I fear
  226.      they are facts of life given the immense installed base.
  227.  
  228.      "Given this situation, and the reality that it won't be feasible
  229.      to coordinate all the infrastructure changes even at the national
  230.      and regional levels, it is imperative that the transition
  231.      capabilities support the ability to deploy the IPng in the
  232.      piecemeal fashion... with no requirement to need to coordinate
  233.      local changes with other changes elsewhere in the Internet...
  234.  
  235.      "I realize that support for the transition and coexistence
  236.      capabilities may be a major part of the IPng effort and may cause
  237.      some headaches for the designers and developers, but I think it is
  238.      a duty that can't be shirked and the necessary price that must be
  239.      paid to provide as seamless an environment as possible to the end
  240.      user and his basic network services such as e-mail, ftp, gopher,
  241.      X-Window clients, etc...
  242.  
  243.      "The bottom line for me is that we must have interoperability
  244.      during the extended transition period for the base IPv4
  245.      functionality..."
  246.  
  247. Another way to think about the requirement for compatibility with IPv4 is to
  248. look at other product areas. In the product world, backwards compatibility
  249. is very important. Vendors who do not provide backward compatibility for
  250. their customers usually find they do not have many customers left. For
  251. example, chip makers put considerable effort into making sure that new
  252. versions of their processor always run all of the software that ran on the
  253. previous model. It is unlikely that Intel would develop a new processor in
  254. the X86 family that did not run DOS and the tens of thousands of
  255. applications which run on the current versions of X86's.
  256.  
  257. Operating system vendors go to great lengths to make sure new versions of
  258. their operating systems are binary compatible with their old version. For
  259. example the labels on most PC or MAC software usually indicate that they
  260. require OS version XX or greater. It would be foolish for Microsoft come out
  261. with a new version of Windows which did not run the applications which ran
  262. on the previous version. Microsoft even provides the ability for windows
  263. applications to run on their new OS NT. This is an important feature. They
  264. understand that it was very important to make sure that the applications
  265. which run on Windows also run on NT.
  266.  
  267. The same requirement is also true for IPng. The Internet has a large
  268. installed base. Features need to be designed into an IPng to make the
  269. transition as easy as possible. As with processors and operating systems, it
  270. must be backwards compatible with IPv4. Other protocols have tried to
  271. replace TCP/IP, for example XTP and OSI. One element in their failure to
  272. reach widespread acceptance was that neither had any transition strategy
  273. other than running in parallel (sometimes called dual stack). New features
  274. alone are not adequate to motivate users to deploy new protocols. IPng must
  275. have a great transition strategy and new features.
  276.  
  277. 3.0 History of the IPng Effort
  278.  
  279. The IPng protocol represents the evolution of many different IETF proposals
  280. and working groups focused on developing an IPng. It represents over three
  281. years of effort focused on this topic. A brief history follows:
  282.  
  283. By the Winter of 1992 the Internet community had developed four separate
  284. proposals for IPng. These were "CNAT", "IP Encaps", "Nimrod", and "Simple
  285. CLNP". By December 1992 three more proposals followed; "The P Internet
  286. Protocol" (PIP), "The Simple Internet Protocol" (SIP) and "TP/IX". In the
  287. Spring of 1992 the "Simple CLNP" evolved into "TCP and UDP with Bigger
  288. Addresses" (TUBA) and "IP Encaps" evolved into "IP Address Encapsulation"
  289. (IPAE).
  290.  
  291. By the fall of 1993, IPAE merged with SIP while still maintaining the name
  292. SIP. This group later merged with PIP and the resulting working group called
  293. themselves "Simple Internet Protocol Plus" (SIPP). At about the same time
  294. the TP/IX Working Group changed its name to "Common Architecture for the
  295. Internet" (CATNIP).
  296.  
  297. The IPng area directors made a recommendation for an IPng in July of 1994.
  298. This recommendation, from [1], includes the following elements:
  299.  
  300.    * Current address assignment policies are adequate.
  301.    * There is no current need to reclaim underutilized assigned network
  302.      numbers.
  303.    * There is no current need to renumber major portions of the Internet.
  304.    * CIDR-style assignments of parts of unassigned Class A address space
  305.      should be considered.
  306.    * "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [3] be
  307.      adopted as the basis for IPng.
  308.    * The documents listed in Appendix C be the foundation of the IPng
  309.      effort.
  310.    * An IPng Working Group be formed, chaired by Steve Deering and Ross
  311.      Callon.
  312.    * Robert Hinden be the document editor for the IPng effort.
  313.    * An IPng Reviewer be appointed and that Dave Clark be the reviewer.
  314.    * An Address Autoconfiguration Working Group be formed, chaired by Dave
  315.      Katz and Sue Thomson.
  316.    * An IPng Transition Working Group be formed, chaired by Bob Gilligan and
  317.      TBA.
  318.    * The Transition and Coexistence Including Testing Working Group be
  319.      chartered.
  320.    * Recommendations about the use of non-IPv6 addresses in IPv6
  321.      environments and IPv6 addresses in non-IPv6 environments be developed.
  322.    * The IESG commission a review of all IETF standards documents for IPng
  323.      implications.
  324.    * The IESG task current IETF working groups to take IPng into account.
  325.    * The IESG charter new working groups where needed to revise old
  326.      standards documents.
  327.    * Informational RFCs be solicited or developed describing a few specific
  328.      IPng APIs.
  329.    * The IPng Area and Area Directorate continue until main documents are
  330.      offered as Proposed Standards in late 1994.
  331.    * Support for the Authentication Header be required.
  332.    * Support for a specific authentication algorithm be required.
  333.    * Support for the Privacy Header be required.
  334.    * Support for a specific privacy algorithm be required.
  335.    * An "IPng framework for firewalls" be developed.
  336.  
  337. 4.0 IPng Overview
  338.  
  339. IPng is a new version of the Internet Protocol, designed as a successor to
  340. IP version 4 [4]. IPng is assigned IP version number 6 and is formally
  341. called IPv6 [5].
  342.  
  343. IPng was designed to take an evolutionary step from IPv4. It was not a
  344. design goal to take a radical step away from IPv4. Functions which work in
  345. IPv4 were kept in IPng. Functions which didn't work were removed. The
  346. changes from IPv4 to IPng fall primarily into the following categories:
  347.  
  348.    * Expanded Routing and Addressing Capabilities
  349.  
  350.      IPng increases the IP address size from 32 bits to 128 bits, to support
  351.      more levels of addressing hierarchy and a much greater number of
  352.      addressable nodes, and simpler auto-configuration of addresses.
  353.  
  354.      The scalability of multicast routing is improved by adding a "scope"
  355.      field to multicast addresses.
  356.  
  357.    * A new type of address called a "anycast address" is defined, to
  358.      identify sets of nodes where a packet sent to an anycast address is
  359.      delivered to one of the nodes. The use of anycast addresses in the IPng
  360.      source route allows nodes to control the path which their traffic
  361.      flows.
  362.  
  363.    * Header Format Simplification
  364.  
  365.      Some IPv4 header fields have been dropped or made optional, to reduce
  366.      the common-case processing cost of packet handling and to keep the
  367.      bandwidth cost of the IPng header as low as possible despite the
  368.      increased size of the addresses. Even though the IPng addresses are
  369.      four time longer than the IPv4 addresses, the IPng header is only twice
  370.      the size of the IPv4 header.
  371.  
  372.    * Improved Support for Options
  373.  
  374.      Changes in the way IP header options are encoded allows for more
  375.      efficient forwarding, less stringent limits on the length of options,
  376.      and greater flexibility for introducing new options in the future.
  377.  
  378.    * Quality-of-Service Capabilities
  379.  
  380.      A new capability is added to enable the labeling of packets belonging
  381.      to particular traffic "flows" for which the sender requests special
  382.      handling, such as non-default quality of service or "real- time"
  383.      service.
  384.    * Authentication and Privacy Capabilities
  385.  
  386.      IPng includes the definition of extensions which provide support for
  387.      authentication, data integrity, and confidentiality. This is included
  388.      as a basic element of IPng and will be included in all implementations.
  389.  
  390. The IPng protocol consists of two parts, the basic IPng header and IPng
  391. extension headers.
  392.  
  393. 5.0 IPng Header Format
  394.  
  395.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  396.    |Version| Prior |                       Flow Label              |
  397.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  398.    |         Payload Length        |  Next Header  |   Hop Limit   |
  399.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  400.    |                                                               |
  401.    +                                                               +
  402.    |                                                               |
  403.    +                         Source Address                        +
  404.    |                                                               |
  405.    +                                                               +
  406.    |                                                               |
  407.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  408.    |                                                               |
  409.    +                                                               +
  410.    |                                                               |
  411.    +                      Destination Address                      +
  412.    |                                                               |
  413.    +                                                               +
  414.    |                                                               |
  415.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416.  
  417. Ver  4-bit Internet Protocol version number = 6.
  418.  
  419. Prio
  420.      4-bit Priority value. See IPng Priority section.
  421.  
  422. Flow Label
  423.      24-bit field. See IPng Quality of Service section.
  424.  
  425. Payload Length
  426.      16-bit unsigned integer. Length of payload, i.e., the rest of the
  427.      packet following the IPng header, in octets.
  428.  
  429. Next Hdr
  430.      8-bit selector. Identifies the type of header immediately following the
  431.      IPng header. Uses the same values as the IPv4 Protocol field [6].
  432.  
  433. Hop Limit
  434.      8-bit unsigned integer. Decremented by 1 by each node that forwards the
  435.      packet. The packet is discarded if Hop Limit is decremented to zero.
  436.  
  437. Source Address
  438.      128 bits. The address of the initial sender of the packet. See [7] for
  439.      details.
  440.  
  441. Destination Address
  442.      128 bits. The address of the intended recipient of the packet (possibly
  443.      not the ultimate recipient, if an optional Routing Header is present).
  444.  
  445. 6.0 IPng Extensions
  446.  
  447. IPng includes an improved option mechanism over IPv4. IPng options are
  448. placed in separate extension headers that are located between the IPng
  449. header and the transport-layer header in a packet. Most IPng extension
  450. headers are not examined or processed by any router along a packet's
  451. delivery path until it arrives at its final destination. This facilitates a
  452. major improvement in router performance for packets containing options. In
  453. IPv4 the presence of any options requires the router to examine all options.
  454.  
  455. The other improvement is that unlike IPv4 options, IPng extension headers
  456. can be of arbitrary length and the total amount of options carried in a
  457. packet is not limited to 40 bytes. This feature plus the manner in which
  458. they are processed, permits IPng options to be used for functions which were
  459. not practical in IPv4. A good example of this is the IPng Authentication and
  460. Security Encapsulation options.
  461.  
  462. In order to improve the performance when handling subsequent option headers
  463. and the transport protocol which follows, IPng options are always an integer
  464. multiple of 8 octets long, in order to retain this alignment for subsequent
  465. headers.
  466.  
  467. The IPng extension headers which are currently defined are:
  468.  
  469. Routing
  470.      Extended Routing (like IPv4 loose source route).
  471.  
  472. Fragmentation
  473.      Fragmentation and Reassembly.
  474.  
  475. Authentication
  476.      Integrity and Authentication. Security
  477.  
  478. Encapsulation
  479.      Confidentiality.
  480.  
  481. Hop-by-Hop Option
  482.      Special options which require hop by hop processing.
  483.  
  484. Destination Options
  485.      Optional information to be examined by the destination node.
  486.  
  487. 7.0 IPng Addressing
  488.  
  489. IPng addresses are 128-bits long and are identifiers for individual
  490. interfaces and sets of interfaces. IPng Addresses of all types are assigned
  491. to interfaces, not nodes. Since each interface belongs to a single node, any
  492. of that node's interfaces' unicast addresses may be used as an identifier
  493. for the node. A single interface may be assigned multiple IPv6 addresses of
  494. any type.
  495.  
  496. There are three types of IPng addresses. These are unicast, anycast, and
  497. multicast. Unicast addresses identify a single interface. Anycast addresses
  498. identify a set of interfaces such that a packet sent to a anycast address
  499. will be delivered to one member of the set. Multicast addresses identify a
  500. group of interfaces, such that a packet sent to a multicast address is
  501. delivered to all of the interfaces in the group. There are no broadcast
  502. addresses in IPv6, their function being superseded by multicast addresses.
  503.  
  504. IPng supports addresses which are four times the number of bits as IPv4
  505. addresses (128 vs. 32). This is 4 Billion times 4 Billion (2^^96) times the
  506. size of the IPv4 address space (2^^32). This works out to be:
  507.  
  508.      340,282,366,920,938,463,463,374,607,431,768,211,456
  509.  
  510. This is an extremely large address space. In a theoretical sense this is
  511. approximately 665,570,793,348,866,943,898,599 addresses per square meter of
  512. the surface of the planet Earth (assuming the earth surface is
  513. 511,263,971,197,990 square meters).
  514.  
  515. In more practical terms the assignment and routing of addresses requires the
  516. creation of hierarchies which reduces the efficiency of the usage of the
  517. address space. Christian Huitema performed an analysis in [8] which
  518. evaluated the efficiency of other addressing architecture's (including the
  519. French telephone system, USA telephone systems, current internet using IPv4,
  520. and IEEE 802 nodes). He concluded that 128bit IPng addresses could
  521. accommodate between 8x10^^17 to 2x10^^33 nodes assuming efficiency in the
  522. same ranges as the other addressing architecture's. Even his most
  523. pessimistic estimate this would provide 1,564 addresses for each square
  524. meter of the surface of the planet Earth. The optimistic estimate would
  525. allow for 3,911,873,538,269,506,102 addresses for each square meter of the
  526. surface of the planet Earth.
  527.  
  528. The specific type of IPng address is indicated by the leading bits in the
  529. address. The variable-length field comprising these leading bits is called
  530. the Format Prefix (FP). The initial allocation of these prefixes is as
  531. follows:
  532.  
  533. Allocation                      Prefix(binary)  Fraction of Address Space
  534.  
  535. Reserved                        0000 0000       1/256
  536. Unassigned                      0000 0001       1/256
  537.  
  538. Reserved for NSAP Allocation    0000 001        1/128
  539. Reserved for IPX Allocation     0000 010        1/128
  540.  
  541. Unassigned                      0000 011        1/128
  542. Unassigned                      0000 1          1/32
  543. Unassigned                      0001            1/16
  544. Unassigned                      001             1/8
  545.  
  546. Provider-Based Unicast Address  010             1/8
  547.  
  548. Unassigned                      011             1/8
  549.  
  550. Reserved for
  551. Neutral-Interconnect-Based
  552. Unicast Addresses               100             1/8
  553.  
  554. Unassigned                      101             1/8
  555. Unassigned                      110             1/8
  556. Unassigned                      1110            1/16
  557. Unassigned                      1111 0          1/32
  558. Unassigned                      1111 10         1/64
  559. Unassigned                      1111 110        1/128
  560. Unassigned                      1111 1110 0     1/512
  561.  
  562. Link Local Use Addresses        1111 1110 10    1/1024
  563.  
  564. Site Local Use Addresses        1111 1110 11    1/1024
  565.  
  566. Multicast Addresses             1111 1111       1/256
  567.  
  568. This allocation supports the direct allocation of provider addresses, local
  569. use addresses, and multicast addresses. Space is reserved for NSAP
  570. addresses, IPX addresses, and neutral-interconnect addresses. The remainder
  571. of the address space is unassigned for future use. This can be used for
  572. expansion of existing use (e.g., additional provider addresses, etc.) or new
  573. uses (e.g., separate locators and identifiers). Note that Anycast addresses
  574. are not shown here because they are allocated out of the unicast address
  575. space.
  576.  
  577. Approximately fifteen percent of the address space is initially allocated.
  578. The remaining 85% is reserved for future use.
  579.  
  580. 7.1 Unicast Addresses
  581.  
  582. There are several forms of unicast address assignment in IPv6. These are the
  583. global provider based unicast address, the neutral-interconnect unicast
  584. address, the NSAP address, the IPX hierarchical address, the site-local-use
  585. address, the link-local-use address, and the IPv4-capable host address.
  586. Additional address types can be defined in the future.
  587.  
  588. 7.2 Provider Based Unicast Addresses
  589.  
  590. Provider based unicast addresses are used for global communication. They are
  591. similar in function to IPv4 addresses under CIDR. The assignment plan for
  592. unicast addresses is described in [9] and [10]. Their format is:
  593.  
  594.      | 3 |  n bits   |  m bits   |   o bits    | p bits  | o-p bits |
  595.      +---+-----------+-----------+-------------+---------+----------+
  596.      |010|REGISTRY ID|PROVIDER ID|SUBSCRIBER ID|SUBNET ID| INTF. ID |
  597.      +---+-----------+-----------+-------------+---------+----------+
  598.  
  599. The first 3 bits identify the address as a provider- oriented unicast
  600. address. The next field (REGISTRY ID) identifies the internet address
  601. registry which assigns provider identifiers (PROVIDER ID) to internet
  602. service providers, which then assign portions of the address space to
  603. subscribers. This usage is similar to assignment of IP addresses under CIDR.
  604. The SUBSCRIBER ID distinguishes among multiple subscribers attached to the
  605. internet service provider identified by the PROVIDER ID. The SUBNET ID
  606. identifies a specific physical link. There can be multiple subnets on the
  607. same physical link. A specific subnet can not span multiple physical links.
  608. The INTERFACE ID identifies a single interface among the group of interfaces
  609. identified by the subnet prefix.
  610.  
  611. 7.3 Local-Use Addresses
  612.  
  613. A local-use address is a unicast address that has only local routability
  614. scope (within the subnet or within a subscriber network), and may have local
  615. or global uniqueness scope. They are intended for use inside of a site for
  616. "plug and play" local communication and for bootstrapping up to the use of
  617. global addresses [11].
  618.  
  619. There are two types of local-use unicast addresses defined. These are
  620. Link-Local and Site-Local. The Link-Local-Use is for use on a single link
  621. and the Site-Local-Use is for use in a single site. Link-Local- Use
  622. addresses have the following format:
  623.  
  624.      |   10     |
  625.      |  bits    |        n bits           |       118-n bits           |
  626.      +----------+-------------------------+----------------------------+
  627.      |1111111010|           0             |       INTERFACE ID         |
  628.      +----------+-------------------------+----------------------------+
  629.  
  630. Link-Local-Use addresses are designed to be used for addressing on a single
  631. link for purposes such as auto-address configuration.
  632.  
  633. Site-Local-Use addresses have the following format:
  634.  
  635.      |   10     |
  636.      |  bits    | n bits  |    m bits     |       118-n-m bits         |
  637.      +----------+---------+---------------+----------------------------+
  638.      |1111111011|    0    |   SUBNET ID   |       INTERFACE ID         |
  639.      +----------+---------+---------------+----------------------------+
  640.  
  641. For both types of local use addresses the INTERFACE ID is an identifier
  642. which much be unique in the domain in which it is being used. In most cases
  643. these will use a node's IEEE-802 48bit address. The SUBNET ID identifies a
  644. specific subnet in a site. The combination of the SUBNET ID and the
  645. INTERFACE ID to form a local use address allows a large private internet to
  646. be constructed without any other address allocation.
  647.  
  648. Local-use addresses allow organizations that are not (yet) connected to the
  649. global Internet to operate without the need to request an address prefix
  650. from the global Internet address space. Local-use addresses can be used
  651. instead. If the organization later connects to the global Internet, it can
  652. use its SUBNET ID and INTERFACE ID in combination with a global prefix
  653. (e.g., REGISTRY ID + PROVIDER ID + SUBSCRIBER ID) to create a global
  654. address. This is a significant improvement over IPv4 which requires sites
  655. which use private (non-global) IPv4 address to manually renumber when they
  656. connect to the Internet. IPng does the renumbering automatically.
  657.  
  658. 7.4 IPv6 Addresses with Embedded IPV4 Addresses
  659.  
  660. The IPv6 transition mechanisms include a technique for hosts and routers to
  661. dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes
  662. that utilize this technique are assigned special IPv6 unicast addresses that
  663. carry an IPv4 address in the low-order 32-bits. This type of address is
  664. termed an "IPv4-compatible IPv6 address" and has the format:
  665.  
  666.      |                80 bits               | 16 |      32 bits        |
  667.      +--------------------------------------+--------------------------+
  668.      |0000..............................0000|0000|    IPV4 ADDRESS     |
  669.      +--------------------------------------+----+---------------------+
  670.  
  671. A second type of IPv6 address which holds an embedded IPv4 address is also
  672. defined. This address is used to represent the addresses of IPv4- only nodes
  673. (those that *do not* support IPv6) as IPv6 addresses. This type of address
  674. is termed an "IPv4-mapped IPv6 address" and has the format:
  675.  
  676.      |                80 bits               | 16 |      32 bits        |
  677.      +--------------------------------------+--------------------------+
  678.      |0000..............................0000|FFFF|    IPV4 ADDRESS     |
  679.      +--------------------------------------+----+---------------------+
  680.  
  681. 7.5 Anycast Addresses
  682.  
  683. An IPv6 anycast address is an address that is assigned to more than one
  684. interfaces (typically belonging to different nodes), with the property that
  685. a packet sent to an anycast address is routed to the "nearest" interface
  686. having that address, according to the routing protocols' measure of
  687. distance.
  688.  
  689. Anycast addresses, when used as part of an route sequence, permits a node to
  690. select which of several internet service providers it wants to carry its
  691. traffic. This capability is sometimes called "source selected policies".
  692. This would be implemented by configuring anycast addresses to identify the
  693. set of routers belonging to internet service providers (e.g., one anycast
  694. address per internet service provider). These anycast addresses can be used
  695. as intermediate addresses in an IPv6 routing header, to cause a packet to be
  696. delivered via a particular provider or sequence of providers. Other possible
  697. uses of anycast addresses are to identify the set of routers attached to a
  698. particular subnet, or the set of routers providing entry into a particular
  699. routing domain.
  700.  
  701. Anycast addresses are allocated from the unicast address space, using any of
  702. the defined unicast address formats. Thus, anycast addresses are
  703. syntactically indistinguishable from unicast addresses. When a unicast
  704. address is assigned to more than one interface, thus turning it into an
  705. anycast address, the nodes to which the address is assigned must be
  706. explicitly configured to know that it is an anycast address.
  707.  
  708. 7.6 Multicast Addresses
  709.  
  710. A IPng multicast address is an identifier for a group of interfaces. A
  711. interface may belong to any number of multicast groups. Multicast addresses
  712. have the following format:
  713.  
  714.  
  715.      |   8    |  4 |  4 |                  112 bits                   |
  716.      +------ -+----+----+---------------------------------------------+
  717.      |11111111|FLGS|SCOP|                  GROUP ID                   |
  718.      +--------+----+----+---------------------------------------------+
  719.  
  720. 11111111 at the start of the address identifies the address as being a
  721.          multicast address.
  722.  
  723.                                 +-+-+-+-+
  724. FLGS is a set of 4 flags:       |0|0|0|T|
  725.                                 +-+-+-+-+
  726.  
  727. The high-order 3 flags are reserved, and must be
  728. initialized to 0.
  729.  
  730. T=0     indicates a permanently assigned ("well-known")
  731.         multicast address, assigned by the global internet
  732.         numbering authority.
  733.  
  734. T=1     indicates a non-permanently assigned ("transient")
  735.         multicast address.
  736.  
  737. SCOP is a 4-bit multicast scope value used to limit
  738. the scope of the multicast group.  The values are:
  739.  
  740. 0  Reserved             8       Organization-local scope
  741. 1  Node-local scope     9       (unassigned)
  742. 2  Link-local scope     A       (unassigned)
  743. 3  (unassigned)         B       (unassigned)
  744. 4  (unassigned)         C       (unassigned)
  745. 5  Site-local scope     D       (unassigned)
  746. 6  (unassigned)         E       Global scope
  747. 7  (unassigned)         F       Reserved
  748.  
  749. GROUP ID identifies the multicast group, either permanent or transient,
  750. within the given scope.
  751.  
  752. 8.0 IPng Routing
  753.  
  754. Routing in IPng is almost identical to IPv4 routing under CIDR except that
  755. the addresses are 128- bit IPng addresses instead of 32-bit IPv4 addresses.
  756. With very straightforward extensions, all of IPv4's routing algorithms
  757. (OSPF, RIP, IDRP, ISIS, etc.) can used to route IPng.
  758.  
  759. IPng also includes simple routing extensions which support powerful new
  760. routing functionality. These capabilities include:
  761.  
  762.    * Provider Selection (based on policy, performance, cost, etc.)
  763.    * Host Mobility (route to current location)
  764.    * Auto-Readdressing (route to new address)
  765.  
  766. The new routing functionality is obtained by creating sequences of IPng
  767. addresses using the IPng Routing option. The routing option is used by a
  768. IPng source to list one or more intermediate nodes (or topological group) to
  769. be "visited" on the way to a packet's destination. This function is very
  770. similar in function to IPv4's Loose Source and Record Route option.
  771.  
  772. In order to make address sequences a general function, IPng hosts are
  773. required in most cases to reverse routes in a packet it receives (if the
  774. packet was successfully authenticated using the IPng Authentication Header)
  775. containing address sequences in order to return the packet to its
  776. originator. This approach is taken to make IPng host implementations from
  777. the start support the handling and reversal of source routes. This is the
  778. key for allowing them to work with hosts which implement the new features
  779. such as provider selection or extended addresses.
  780.  
  781. Three examples show how the address sequences can be used. In these
  782. examples, address sequences are shown by a list of individual addresses
  783. separated by commas. For example:
  784.  
  785.      SRC, I1, I2, I3, DST
  786.  
  787. Where the first address is the source address, the last address is the
  788. destination address, and the middle addresses are intermediate addresses.
  789.  
  790. For these examples assume that two hosts, H1 and H2 wish to communicate.
  791. Assume that H1 and H2's sites are both connected to providers P1 and P2. A
  792. third wireless provider, PR, is connected to both providers P1 and P2.
  793.  
  794.                            ----- P1 ------
  795.                           /       |       \
  796.                          /        |        \
  797.                        H1        PR        H2
  798.                          \        |        /
  799.                           \       |       /
  800.                            ----- P2 ------
  801.  
  802. The simplest case (no use of address sequences) is when H1 wants to send a
  803. packet to H2 containing the addresses:
  804.  
  805.      H1, H2
  806.  
  807. When H2 replied it would reverse the addresses and construct a packet
  808. containing the addresses:
  809.  
  810.      H2, H1
  811.  
  812. In this example either provider could be used, and H1 and H2 would not be
  813. able to select which provider traffic would be sent to and received from.
  814.  
  815. If H1 decides that it wants to enforce a policy that all communication
  816. to/from H2 can only use provider P1, it would construct a packet containing
  817. the address sequence:
  818.  
  819.      H1, P1, H2
  820.  
  821. This ensures that when H2 replies to H1, it will reverse the route and the
  822. reply it would also travel over P1. The addresses in H2's reply would look
  823. like:
  824.  
  825.      H2, P1, H1
  826.  
  827. If H1 became mobile and moved to provider PR, it could maintain (not
  828. breaking any transport connections) communication with H2, by sending
  829. packets that contain the address sequence:
  830.  
  831.      H1, PR, P1, H2
  832.  
  833. This would ensure that when H2 replied it would enforce H1's policy of
  834. exclusive use of provider P1 and send the packet to H1 new location on
  835. provider PR. The reversed address sequence would be:
  836.  
  837.      H2, P1, PR, H1
  838.  
  839. The address sequence facility of IPng can be used for provider selection,
  840. mobility, and readdressing. It is a simple but powerful capability.
  841.  
  842. 9.0 IPng Quality-of-Service Capabilities
  843.  
  844. The Flow Label and the Priority fields in the IPng header may be used by a
  845. host to identify those packets for which it requests special handling by
  846. IPng routers, such as non-default quality of service or "real-time" service.
  847. This capability is important in order to support applications which require
  848. some degree of consistent throughput, delay, and/or jitter. These type of
  849. applications are commonly described as "multi- media" or "real-time"
  850. applications.
  851.  
  852. 9.1 Flow Labels
  853.  
  854. The 24-bit Flow Label field in the IPv6 header may be used by a source to
  855. label those packets for which it requests special handling by the IPv6
  856. routers, such as non-default quality of service or "real-time" service.
  857.  
  858. This aspect of IPv6 is, at the time of writing, still experimental and
  859. subject to change as the requirements for flow support in the Internet
  860. become clearer. Hosts or routers that do not support the functions of the
  861. Flow Label field are required to set the field to zero when originating a
  862. packet, pass the field on unchanged when forwarding a packet, and ignore the
  863. field when receiving a packet.
  864.  
  865. A flow is a sequence of packets sent from a particular source to a
  866. particular (unicast or multicast) destination for which the source desires
  867. special handling by the intervening routers. The nature of that special
  868. handling might be conveyed to the routers by a control protocol, such as a
  869. resource reservation protocol, or by information within the flow's packets
  870. themselves, e.g., in a hop-by-hop option.
  871.  
  872. There may be multiple active flows from a source to a destination, as well
  873. as traffic that is not associated with any flow. A flow is uniquely
  874. identified by the combination of a source address and a non- zero flow
  875. label. Packets that do not belong to a flow carry a flow label of zero.
  876.  
  877. A flow label is assigned to a flow by the flow's source node. New flow
  878. labels must be chosen (pseudo-)randomly and uniformly from the range 1 to
  879. FFFFFF hex. The purpose of the random allocation is to make any set of bits
  880. within the Flow Label field suitable for use as a hash key by routers, for
  881. looking up the state associated with the flow.
  882.  
  883. All packets belonging to the same flow must be sent with the same source
  884. address, same destination address, and same non-zero flow label. If any of
  885. those packets includes a Hop-by-Hop Options header, then they all must be
  886. originated with the same Hop-by-Hop Options header contents (excluding the
  887. Next Header field of the Hop-by-Hop Options header). If any of those packets
  888. includes a Routing header, then they all must be originated with the same
  889. contents in all extension headers up to and including the Routing header
  890. (excluding the Next Header field in the Routing header). The routers or
  891. destinations are permitted, but not required, to verify that these
  892. conditions are satisfied. If a violation is detected, it should be reported
  893. to the source by an ICMP Parameter Problem message, Code 0, pointing to the
  894. high-order octet of the Flow Label field (i.e., offset 1 within the IPv6
  895. packet) [12].
  896.  
  897. Routers are free to "opportunistically" set up flow- handling state for any
  898. flow, even when no explicit flow establishment information has been provided
  899. to them via a control protocol, a hop-by-hop option, or other means. For
  900. example, upon receiving a packet from a particular source with an unknown,
  901. non-zero flow label, a router may process its IPv6 header and any necessary
  902. extension headers as if the flow label were zero. That processing would
  903. include determining the next-hop interface, and possibly other actions, such
  904. as updating a hop-by-hop option, advancing the pointer and addresses in a
  905. Routing header, or deciding on how to queue the packet based on its Priority
  906. field. The router may then choose to "remember" the results of those
  907. processing steps and cache that information, using the source address plus
  908. the flow label as the cache key. Subsequent packets with the same source
  909. address and flow label may then be handled by referring to the cached
  910. information rather than examining all those fields that, according to the
  911. requirements of the previous paragraph, can be assumed unchanged from the
  912. first packet seen in the flow.
  913.  
  914. 9.2 Priority
  915.  
  916. The 4-bit Priority field in the IPv6 header enables a source to identify the
  917. desired delivery priority of its packets, relative to other packets from the
  918. same source. The Priority values are divided into two ranges: Values 0
  919. through 7 are used to specify the priority of traffic for which the source
  920. is providing congestion control, i.e., traffic that "backs off" in response
  921. to congestion, such as TCP traffic. Values 8 through 15 are used to specify
  922. the priority of traffic that does not back off in response to congestion,
  923. e.g., "real-time" packets being sent at a constant rate.
  924.  
  925. For congestion-controlled traffic, the following Priority values are
  926. recommended for particular application categories:
  927.  
  928.      0    Uncharacterized traffic
  929.      1    "Filler" traffic (e.g., netnews)
  930.      2    Unattended data transfer (e.g., email)
  931.      3    (Reserved)
  932.      4    Attended bulk transfer (e.g., FTP, HTTP, NFS)
  933.      5    (Reserved)
  934.      6    Interactive traffic (e.g., telnet, X)
  935.      7    Internet control traffic (e.g., routing protocols, SNMP)
  936.  
  937. For non-congestion-controlled traffic, the lowest Priority value (8) should
  938. be used for those packets that the sender is most willing to have discarded
  939. under conditions of congestion (e.g., high-fidelity video traffic), and the
  940. highest value (15) should be used for those packets that the sender is least
  941. willing to have discarded (e.g., low-fidelity audio traffic). There is no
  942. relative ordering implied between the congestion-controlled priorities and
  943. the non-congestion-controlled priorities.
  944.  
  945. 10. IPng Security
  946.  
  947. The current Internet has a number of security problems and lacks effective
  948. privacy and authentication mechanisms below the application layer. IPng
  949. remedies these shortcomings by having two integrated options that provide
  950. security services [13]. These two options may be used singly or together to
  951. provide differing levels of security to different users. This is very
  952. important because different user communities have different security needs.
  953.  
  954. The first mechanism, called the "IPng Authentication Header", is an
  955. extension header which provides authentication and integrity (without
  956. confidentiality) to IPng datagrams [14]. While the extension is algorithm-
  957. independent and will support many different authentication techniques, the
  958. use of keyed MD5 is proposed to help ensure interoperability within the
  959. worldwide Internet. This can be used to eliminate a significant class of
  960. network attacks, including host masquerading attacks. The use of the IPng
  961. Authentication Header is particularly important when source routing is used
  962. with IPng because of the known risks in IP source routing. Its placement at
  963. the internet layer can help provide host origin authentication to those
  964. upper layer protocols and services that currently lack meaningful
  965. protections. This mechanism should be exportable by vendors in the United
  966. States and other countries with similar export restrictions because it only
  967. provides authentication and integrity, and specifically does not provide
  968. confidentiality. The exportability of the IPng Authentication Header
  969. encourages its widespread deployment and use.
  970.  
  971. The second security extension header provided with IPng is the "IPng
  972. Encapsulating Security Header" [15]. This mechanism provides integrity and
  973. confidentiality to IPng datagrams. It is simpler than some similar security
  974. protocols (e.g., SP3D, ISO NLSP) but remains flexible and
  975. algorithm-independent. To achieve interoperability within the global
  976. Internet, the use of DES CBC is being used as the standard algorithm for use
  977. with the IPng Encapsulating Security Header.
  978.  
  979. 11. IPng Transition Mechanisms
  980.  
  981. The key transition objective is to allow IPv6 and IPv4 hosts to
  982. interoperate. A second objective is to allow IPv6 hosts and routers to be
  983. deployed in the Internet in a highly diffuse and incremental fashion, with
  984. few interdependencies. A third objective is that the transition should be as
  985. easy as possible for end- users, system administrators, and network
  986. operators to understand and carry out.
  987.  
  988. The IPng transition mechanisms are a set of protocol mechanisms implemented
  989. in hosts and routers, along with some operational guidelines for addressing
  990. and deployment, designed to make transition the Internet to IPv6 work with
  991. as little disruption as possible [16].
  992.  
  993. The IPng transition mechanisms provides a number of features, including:
  994.  
  995.    * Incremental upgrade and deployment. Individual IPv4 hosts and routers
  996.      may be upgraded to IPv6 one at a time without requiring any other hosts
  997.      or routers to be upgraded at the same time. New IPv6 hosts and routers
  998.      can be installed one by one.
  999.    * Minimal upgrade dependencies. The only prerequisite to upgrading hosts
  1000.      to IPv6 is that the DNS server must first be upgraded to handle IPv6
  1001.      address records. There are no pre-requisites to upgrading routers.
  1002.    * Easy Addressing. When existing installed IPv4 hosts or routers are
  1003.      upgraded to IPv6, they may continue to use their existing address. They
  1004.      do not need to be assigned new addresses. Administrators do not need to
  1005.      draft new addressing plans.
  1006.    * Low start-up costs. Little or no preparation work is needed in order to
  1007.      upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems.
  1008.      The mechanisms employed by the IPng transition mechanisms include:
  1009.    * An IPv6 addressing structure that embeds IPv4 addresses within IPv6
  1010.      addresses, and encodes other information used by the transition
  1011.      mechanisms.
  1012.    * A model of deployment where all hosts and routers upgraded to IPv6 in
  1013.      the early transition phase are "dual" capable (i.e. implement complete
  1014.      IPv4 and IPv6 protocol stacks).
  1015.    * The technique of encapsulating IPv6 packets within IPv4 headers to
  1016.      carry them over segments of the end-to-end path where the routers have
  1017.      not yet been upgraded to IPv6.
  1018.    * The header translation technique to allow the eventual introduction of
  1019.      routing topologies that route only IPv6 traffic, and the deployment of
  1020.      hosts that support only IPv6. Use of this technique is optional, and
  1021.      would be used in the later phase of transition if it is used at all.
  1022.  
  1023. The IPng transition mechanisms ensures that IPv6 hosts can interoperate with
  1024. IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses
  1025. run out, and allows IPv6 and IPv4 hosts within a limited scope to
  1026. interoperate indefinitely after that. This feature protects the huge
  1027. investment users have made in IPv4 and ensures that IPv6 does not render
  1028. IPv4 obsolete. Hosts that need only a limited connectivity range (e.g.,
  1029. printers) need never be upgraded to IPv6.
  1030.  
  1031. The incremental upgrade features of the IPng transition mechanisms allow the
  1032. host and router vendors to integrate IPv6 into their product lines at their
  1033. own pace, and allows the end users and network operators to deploy IPng on
  1034. their own schedules.
  1035.  
  1036. 12. Why IPng?
  1037.  
  1038. There are a number of reasons why IPng is appropriate for the next
  1039. generation of the Internet Protocol. It solves the Internet scaling problem,
  1040. provides a flexible transition mechanism for the current Internet, and was
  1041. designed to meet the needs of new markets such as nomadic personal computing
  1042. devices, networked entertainment, and device control. It does this in a
  1043. evolutionary way which reduces the risk of architectural problems.
  1044.  
  1045. Ease of transition is a key point in the design of IPng. It is not something
  1046. was added in at the end. IPng is designed to interoperate with IPv4.
  1047. Specific mechanisms (embedded IPv4 addresses, pseudo- checksum rules etc.)
  1048. were built into IPng to support transition and compatibility with IPv4. It
  1049. was designed to permit a gradual and piecemeal deployment with a minimum of
  1050. dependencies.
  1051.  
  1052. IPng supports large hierarchical addresses which will allow the Internet to
  1053. continue to grow and provide new routing capabilities not built into IPv4.
  1054. It has anycast addresses which can be used for policy route selection and
  1055. has scoped multicast addresses which provide improved scalability over IPv4
  1056. multicast. It also has local use address mechanisms which provide the
  1057. ability for "plug and play" installation.
  1058.  
  1059. The address structure of IPng was also designed to support carrying the
  1060. addresses of other internet protocol suites. Space was allocated in the
  1061. addressing plan for IPX and NSAP addresses. This was done to facilitate
  1062. migration of these internet protocols to IPng.
  1063.  
  1064. IPng provides a platform for new Internet functionality. This includes
  1065. support for real-time flows, provider selection, host mobility, end-to- end
  1066. security, auto-configuration, and auto-reconfiguration.
  1067.  
  1068. In summary, IPng is a new version of IP. It can be installed as a normal
  1069. software upgrade in internet devices. It is interoperable with the current
  1070. IPv4. Its deployment strategy was designed to not have any "flag" days. IPng
  1071. is designed to run well on high performance networks (e.g., ATM) and at the
  1072. same time is still efficient for low bandwidth networks (e.g., wireless). In
  1073. addition, it provides a platform for new internet functionality that will be
  1074. required in the near future.
  1075.  
  1076. 13. Where to Get Additional Information
  1077.  
  1078. A set of world wide web (WWW) pages is available describing IPng. It can be
  1079. found at
  1080.  
  1081. http://playground.sun.com/pub/ipng/html/ipng-main.html
  1082.  
  1083. These web pages contain pointers to current specifications and
  1084. implementations and will be updated on a regular basis.
  1085.  
  1086. The documentation listed in the reference sections can be found in one of
  1087. the IETF internet draft directories.
  1088.  
  1089. To join the IPng working group, send an electronic mail message to:
  1090.  
  1091.      majordomo@sunroof.eng.sun.com
  1092.  
  1093. with
  1094.  
  1095.      subscribe ipng
  1096.  
  1097. in the body portion of the message.
  1098.  
  1099. An archive of mail sent to this mailing list can be found in the IETF
  1100. directories at cnri.reston.va.us.
  1101.  
  1102. ----------------------------------------------------------------------------
  1103.  
  1104. References
  1105.  
  1106. [1]  S. Bradner, A. Mankin, RFC 1752, "The Recommendation for the IP Next
  1107.      Generation Protocol", January 1995.
  1108.  
  1109. [2]  V. Fuller, et al, "Supernetting: an Address Assignment and Aggregation
  1110.      Strategy", RFC 1338, June 1992.
  1111.  
  1112. [3]  S. Deering, "Simple Internet Protocol Plus (SIPP) Specification
  1113.      (128-bit address version)", Internet Draft, July 1994.
  1114.  
  1115. [4]  J. Postel, "Internet Protocol", RFC-791, September, 1981.
  1116.  
  1117. [5]  S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6)
  1118.      Specification", Internet Draft, March 1995.
  1119.  
  1120. [6]  J. Postel, "Assigned Numbers", RFC-1700, October 1994.
  1121.  
  1122. [7]  R. Hinden, Editor, "IP Version 6 Addressing Architecture", Internet
  1123.      Draft, April 1995.
  1124.  
  1125. [8]  C. Huitema, "The H Ratio for Address Assignment Efficiency" RFC-1715,
  1126.      November 1994.
  1127.  
  1128. [9]  Y. Rekhter, T. Li, "An Architecture for IPv6 Unicast Address
  1129.      Allocation", Internet Draft, March 1995.
  1130.  
  1131. [10] Y. Rekhter, P. Lothberg, "An IPv6 Global Unicast Address Format",
  1132.      Internet Draft, March 1995.
  1133.  
  1134. [11] S. Thomson, "IPv6 Address Autoconfiguration", Internet Draft, February
  1135.      1995.
  1136.  
  1137. [12] A. Conta, S. Deering, "ICMP for the Internet Protocol Version 6
  1138.      (IPv6)", Internet Draft, January 1995.
  1139.  
  1140. [13] R. Atkinson, "IPv6 Security Architecture" Internet Draft, March 1995.
  1141.  
  1142. [14] R. Atkinson, "IP Authentication Header", Internet Draft, March 1995.
  1143.  
  1144. [15] R. Atkinson, "IPng Encapsulating Security Payload (ESP)", March 1995.
  1145.  
  1146. [16] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
  1147.      Routers", Internet Draft, March 1995.
  1148.  
  1149. ----------------------------------------------------------------------------
  1150.  
  1151. Author Information
  1152.  
  1153. Robert M. Hinden
  1154.  
  1155. [Image]
  1156.  
  1157. Robert M. Hinden holds an B.S.E.E., and a M.S. in Computer Science from
  1158. Union College, Schenectady, New York.
  1159.  
  1160. Mr. Hinden is Director of Software at Ipsilon Networks, Inc. of Mountain
  1161. View , California. Ipsilon Networks is a startup working in the area of high
  1162. performance internetworking and ATM. Mr. Hinden was previously employed at
  1163. Sun Microsystems where he was responsible for the department which develops
  1164. internet protocols for Sun's operating systems. Prior to this he worked at
  1165. Bolt, Beranek, and Newman, Inc. on a variety of internetwork related
  1166. projects including the first operational internet router and one of the
  1167. first TCP/IP implementations.
  1168.  
  1169. He has been active in the IETF since 1985 and is currently the document
  1170. editor for the IPng working group and a member of the IPng Directorate. He
  1171. served as the Area Director for Routing in the Internet Engineering Steering
  1172. group from 1987 to 1994 and previously co-chaired the Simple Internet
  1173. Protocol Plus working group and chaired the IP over ATM and the Open Routing
  1174. working groups.
  1175.  
  1176. He can be reached on the Internet at hinden@ipsilon.com.
  1177.  
  1178. ----------------------------------------------------------------------------
  1179. ----------------------------------------------------------------------------
  1180.  
  1181. Return to the Table of Contents
  1182.  
  1183. ----------------------------------------------------------------------------
  1184. ----------------------------------------------------------------------------
  1185.